1. Field of the Invention
This invention relates to a distributed processing system, particularly to transaction processing on the distributed database system, and more particularly to transaction processing in a Key-Value Store (hereinafter abbreviated as KVS) system.
2. Description of Related Art
The distributed database system is widely known. For example, Japanese Patent Application Publication No. 2007-188518 discloses a distributed database system using ownership groups, in which a step of changing data indicative of the ownership of data items is an atomic operation.
The distributed database system typically implements a relational database and uses query syntax such as SQL.
More recently, database management software called a key-value store (KVS) to write a value by associating a key to the value and read a value by specifying a key associated the value has been used. The features of the simple interface cause high throughput for reading and writing value and high scalability according to the number of servers. Therefore, a distributed KVS capable of distributing data to multiple servers has also been implemented.
In the distributed database system, a distributed transaction using two-phase commit is generally processed. The transaction state is managed by each resource manager and transaction monitor to achieve a transaction across multiple distributed resources. However, if such a mechanism is introduced into a KVS, the simple attribute of the KVS will be lost, resulting in impairing management convenience and scalability. Therefore, it is not preferred to apply, to a distributed KVS, a technique for using a distributed lock manager to achieve a global transaction as disclosed in Japanese Patent Application Publication (Translation of PCT Application) No. 2009-525536. Therefore, in a common distributed KVS, it is required that a client can request only a transaction (local transaction) in each server and a transaction for data managed by multiple servers should be processed to achieve a distributed transaction (global transaction) by combining local transactions.
However, in a transaction distributed KVS simply implemented, no global transaction can be achieved. For example, when one client computer makes a request to two servers for two local transactions to compose one global transaction, if a failure occurs in the client computer after committing one of the local transactions on the server, it cannot be determined whether the other local transaction on the server can be committed.
Therefore, a method for coordinating a global transaction with local transactions on Google App Engine is disclosed in Slim3 on Google App Engine for Java: Development of cloud applications with Slim3, Yasuo Higa and Shinich Ogawa, Shuwa System Co. Ltd., pp. 241-251. In this method, on KVS, a management map is defined as a special map to manage all of global transactions and data maps are defined by application as maps to store not only committed value, but also dirty value being updated with IDs of updating global transactions. The management map manages which global transactions were committed or not as the transaction monitor in the two-phase commit mechanism, and data maps manage which data is prepared to be committed as the resource manages in the two-phase commit mechanism, thereby they realize the same function as the two-phase commit on a distributed KVS that supports only local transactions. The concurrency of the data operations are controlled by transaction IDs in the data maps and the global transaction states in the management map. In other word, in the concurrency control mechanism, concurrency control mechanism (local concurrency control mechanism) for local transactions provided by the KVS is never used.
When a global transaction on a distributed KVS is realized by such a conventionally known technique, a global transaction and a local transaction cannot be mixed because the concurrency control mechanism for local transactions does not work with a concurrency control mechanism for global transactions. For example, when a client computer is updating values managed by two servers with coordinating a global transaction to atomically update them, the other client can read and update the values which are being updated in a local transaction because the concurrency control for the global transaction doesn't acquire any locks from local concurrency control mechanisms of servers on KVS.
Thus, even processing that will do with a local transaction in the technique conventionally known needs to be performed by a global transaction. Since the global transaction has overhead larger than the local transaction, there has been a problem of reducing the processing speed.